This invention relates generally to processes utilized within an enterprise, and more specifically to process development and integration of processes for use across multiple programs of an enterprise that provide products and/or services to customers.
Larger enterprises (e.g., governments, large corporations) frequently use hundreds, and possibly thousands, of different processes in order to perform a single service or manufacture a single product. Many of these processes, and the computing systems that support them, could be shared across many different services and/or products. However, without the ability to find and use common and similar processes across multiple product/service lines, to control variations in those processes, and to integrate those processes, each program must invent their own set of processes, and the computing systems that support the processes. These processes and systems must be maintained for the lifetime of the product/service which can be 50 years or more. This is extremely expensive. For example, a large corporation could have 100 major programs developing complex products, with each program having a lifetime of 50 years. The development and improvement of these products could consist of thousands of processes linked together into scenarios. Many of these processes rely on complex customized computing systems to support them. Typically, 75% or more of the processes and computing systems could be common (or common with minor variations) across the programs. If this commonality were not harnessed and managed, each of the programs would have to develop the processes and their supporting computing systems independently, and maintain them over their 50 year life spans. In the course of process maintenance, multiple versions of a particular process may come into existence.
Typically corporations define processes using a document-based or text-based approach, even if the documents are digitally-based flowcharts and descriptions. In this approach, the intelligence of the process is in the eye of the beholder. Specifically, users of these processes have to read and interpret the process steps, their inputs and outputs, and the roles and computing involved, in order retrieve or analyze any information about the process and interpretations by multiple users can vary. Simply put, a text-based process approach has no structure and must be interpreted by a human. A model-based definition has a defined structure and can be interpreted by software, which can then edit, analyze and integrate the process. In many of these text-based approaches, software-based analyses and integration cannot be enabled because the structure of the definitions is not well-defined or controlled. In order to integrate the processes used by a program (by connecting their inputs and outputs) and to manage their re-use and variation by other programs, the processes must be captured in computer-based business models. By modeling processes, they can be integrated (their inputs and outputs can be connected and their names and definitions made common and shared), the inputs/outputs can be defined precisely, common resource definitions for performing the process can be assigned, and the process can be analyzed to reduce inefficiencies within the process steps. The process execution can be simulated and resource usage can be tracked and even forecasted using such a model. In large-scale complex processes, it is not practical to integrate, analyze and manage the processes that are document-based. A model-based, computer-sensical representation is needed.
Processes typically are not managed enterprise-wide. Rather, the processes are managed in connection with delivering a certain service or in producing a particular end product, and not necessarily across services and across product lines. Such processes are not managed across service and product lines because, at least in part, it is extremely difficult to characterize, define and capture all information related to such processes.